Skip to content

Allow setting token endpoint auth method on ClientOAuthOptions (#1612)#1615

Open
mikeholczer wants to merge 1 commit into
modelcontextprotocol:mainfrom
mikeholczer:feature/1612-allow-setting-token-auth-method
Open

Allow setting token endpoint auth method on ClientOAuthOptions (#1612)#1615
mikeholczer wants to merge 1 commit into
modelcontextprotocol:mainfrom
mikeholczer:feature/1612-allow-setting-token-auth-method

Conversation

@mikeholczer
Copy link
Copy Markdown

Add ClientOAuthOptions.TokenEndpointAuthMethod to override the token_endpoint_auth_method otherwise inferred from DCR or the server's advertised methods. Needed for CIMD public clients that must use "none" even when the server advertises client_secret_basic first (e.g. Auth0). An explicit value now takes precedence over the DCR-returned method.

Motivation and Context

When a client does not explicitly configure a token endpoint authentication method, ClientOAuthProvider infers it — from the dynamic client registration (DCR) response when DCR is used, otherwise from the first entry in the authorization server's token_endpoint_auth_methods_supported.

That inference is wrong for a public client identified by a Client ID Metadata Document (CIMD). Such a client has no secret and must authenticate with "none" (relying on PKCE). But some authorization servers (e.g. Auth0) advertise client_secret_basic ahead of none, so the client falls back to client_secret_basic, sends the client id with an empty secret in the Authorization header instead of placing the client id in the body, and the token exchange fails. This makes CIMD against such servers impossible today.

There was previously no way for the caller to override this. This PR adds ClientOAuthOptions.TokenEndpointAuthMethod so the method can be set explicitly, and makes an explicitly-configured value take precedence over the value returned by DCR.

How Has This Been Tested?

Tested with our real application which uses CIMD and Auth0 as it's authorization server.

Added two integration tests in AuthTests exercising a CIMD client against a test OAuth server configured (Auth0-like) to advertise client_secret_basic ahead of none:

  • CannotAuthenticate_WithClientMetadataDocument_WhenServerAdvertisesClientSecretBasicFirst — confirms the failure when no explicit method is set.
  • CanAuthenticate_WithClientMetadataDocument_AndExplicitNoneAuthMethod — confirms success when TokenEndpointAuthMethod = "none" is set explicitly.

The test OAuth server gained a configurable SupportedTokenEndpointAuthMethods property to mimic these servers. All 40 OAuth.AuthTests pass locally on net8.0, net9.0, and net10.0.

Breaking Changes

None. The new property is optional and defaults to null, preserving the existing inference behavior. The DCR code path now uses ??= so it only applies the registration-returned method when no explicit value was configured — unchanged for callers who don't set the new property.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling (none needed — the token request path already defaults unrecognized auth methods to client_secret_post; this change adds no new failure
    modes)
  • I have added or updated documentation as needed

Additional context

Fixes #1612.

The override is implemented in PerformDynamicClientRegistrationAsync by changing the assignment of the registration-returned method from = to ??=, and by seeding _tokenEndpointAuthMethod from options.TokenEndpointAuthMethod in the constructor. The new property's XML docs describe the inference fallback and call out the CIMD/public-client case explicitly.

…contextprotocol#1612)

Add ClientOAuthOptions.TokenEndpointAuthMethod to override the token_endpoint_auth_method otherwise inferred from DCR or the server's advertised methods. Needed for CIMD public clients that must use "none" even when the server advertises client_secret_basic first (e.g. Auth0). An explicit value now takes precedence over the DCR-returned method.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Can't implement a CIMD client if auth provider doesn't put "none" first in it's list of supported token auth methods

3 participants